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A Distributed Capability Computing System (DCCS) 


Tnis paper describes a distributed computing system. The first 
portion introduces an idealized operating system called CCS 
(Capability Computing System). In the second portion, the DCCS 
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protocols are defined ana the processes necessary to Support the 
DCCS on a CCS are described., The remainder of the paper discusses 


utilizing tne DCCS protocol in a computer network involving 
heterogeneous systems and presents Some applications. The 
applications presented are to optimally solve the single copy 


problem for distributed data bases and to construct a transparent 


= network resource optimization mechanism. 
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Tne Capability Computing system (CCS) 2 


The CCS, though not exactiy like any existing operating system, 

is much like some of tne existing capability list (C-list) 

operating systems described in the literature [i-7]. Many of the 
features of the CCS come from a Proposed modification to the RATS 
operating system [i-3]. 2a 


In the documentation for most computer systems there are many 
references to different types of objects. Typical objects 

discussed are; files, processes, jobs, accounts, semaphores, 

tasks, words, devices, forks, events, etc. etc.. Une of the 

intents ot Cwlist systems is to provide a uniform method of 

access to all such objects. Having all CCS objects accessed 

through a uniform mecnanism allows the DCCS to be implemented in 

a type independent manner. 2b 


The CCS is a multiprocessing system Supporting an active element 
calied a process. For most purposes, the reader’s intuitive 
notion of what a process is should suttice. A process iS capable 
of executing instructions like those in commercially available 
computers. it nas a memory area associated with it and has some 
status indicators like "RUN" and "WAIT", In Cellist systems, 
however, a process also has a Capability list (Cerlist). This list 
is an area in which pointers to the objects that the process is 
allowed to access are maintained. These pointers are protected py 
the system. The process itself is only allowed to use its Cellist 
as a source oi capabilities to access and as a repository tor 
capabilities that it has been granted. Figure 1. diagrams some 
typical processes that are discussed later. In the diagrams, the 
left half of a process box is the Cellist and the right halt is 
the memory. 2c 


Tne key to the uniform access method in the CCS is the invocation 
mechanism. This is the mechanism by which a process makes a 

request on a Capability in its Celist. An invocation is closely 
analogous to a subroutine call on most computer systems. when a 
request is made, the invoking process passes Some Parameters to a 
service routine and receives some parameters in return. 2d 


There are, however, several major differences between the 
invocation mechanism and the usual Subroutine calling mechanisms, 
Tne first ditrerence is that the service routine called is 
generally not in the process’sS memory Space. Tne service routine 
is pointed to by the protected capability and can be implemented 
in hardware, microcode, system kernel code, in another arbitrary 
process, or, aS we shalli see in the DCCS, in another computer 
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system. In Fig. 1. for example, the serving process is servicing 
an invocation on the semaphore requestor. 2e 


A second difference is that, when invoking a capability, other 
capabilities can pe passed and returned aiong witn strictly data 
parameters. Ín the DCCS, capabilities and data can also be passed 
tnrough a communication network. E 


Tne final important distinction of the invocation mechanism can 
pest be illustrated by considering the anaiogy to the outside 
teller windows often seen at banks. These windows usually contain 
a drawer that can be opened py the customer or by the teller, but 
not py both. Except tor tnis drawer, the customer and teiler are 
physically isolated, In the case of the invocation mechanism, the 
invoking process explicitly passes certain capabilities ana 
information to the service routine and designates C-list 
locations and memory areas for the return parameters. Except for 
these parameters, the invoking process and the serving routine 
are isolated. In the DCCS, this protection mechanism is extended 
throughout a network of systems. 2g 


In the CCS, invoking a capability is the only way that a process 

can pass or receive information or capabilities. All of wnat are 
often referred to as system calls on a typical operating system 

are invocations on appropriate capabilities in the CCS. A CCS 

Celist envelopes its process. this fact is needed in order to 
transparently move processes as described in the second 

application on network optimization (page 23). 2N 


CCS Capabilities 3 


To buiid the DCCS, we Will assume certain primitive capabilities 

in the CCS. The invocations below are presented for simplicity 

rather than for efficiency or practicality. In practice, 

capabilities generally nave more highly optimized invocations 

with various error returns, etc.. To characterize a capability, 

it suffices to describe what it returns as a function of what it 

is passed. In the notation used below, the passed parameter list 

is followed by a ">" and tnen the returned parameter list. In 

each parameter list the data parameters are followed by a "3" ana 
then the capability parameters. 3a 


1, File capability 3ai 


a. "Read", index; > data; 
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"Read" the data at the specified index. "Reaa" and tne 
index are passed. Data is returned, 


"Write", index, data; > i 
write the data into the area at the specified index. 


"Write", the index, and the data are passed. Nothing is 
returned. 


Directory capability 


a. 


"Take", index; > ; capability 


"Take" the capability from the specified index in the 
airectory. "Take" and the index are passed. The 
capability is returned. 


"Give", index; capability> ; 


"Give" the capability to the directory at the index 
specified. "Give" and the index are passed information. 
The capability is also passed. Nothing is returned, 


"Find"; capability> result, index; 


A directory, like a processes Cellist, is a repository 
for capabilities. The first two invocations Sre 
analogous to the two file invocations presented except 
that they involve capability parameters moved between 
directory and Cerlist instead of between tile and memory. 
Tne last invocation searches the directory for the 
passed capability. If an identical capability is found, 
"Yes" and tne smailest index ot such a capability are 
returned. Otherwise "No" and O are returned, 


Nil capability 


when a directory is initially created, it contains only Nil 
capabilities. Nil Always returns "Empty";. 


Process capability 


ae 


De 


Ce. 


"Read", index; > data; 
"write", index, data; > ; 


"Take", index; > ; capability 


3a2 


3a3 


3a4 
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a. "Give", index; capability> ; 
e, "Find"; capability> result, index; 
fe "Start"; > 3; 


J. "Stop"; zt 
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Tne a. and b., invocations go to the process’s memory space. 


Cs, Ger and e, go to its Cerlist. F. and g. start and stop 
process execution. 


The CCS Extension Mechanism 


There is one more basic capability mechanism needed for the CCS 
implementation of the DCCS, This mechanism allows processes to 
set themselves up to create new capabilities that they can 
service, Such mechanisms differ widely on existing Cellist 
systems. A workabie mechanism is described, Another primitive 
capability is needed to start thinas off: 


5. Server capability 

a. "Create requestor", requestor number; > Sr requestor 

b. "My requestor?"; capability> answer, requestor number; 

ce. "Wait"; > reason, requestor number, PD; request 
Two capabilities were introduced above besides the server, the 
requestor and request capabilities. These capabilities will be 
descriped as the invocations on a server are described. 
Tne first invocation creates and returns a requestor capability. 


The number that is passed is associated with the requestor, The 
requestor capability is the new capability being created. Any 


4a 


4al 


4b 


sort of invocation can be performed on a requestor. This is tneir 


whole reason for existence. A Grocess With a server capability 
can make a requestor look like any Kind of capability, 


Ine "My requestor?" invocation can be usea to determine if a 
capability is a requestor on the invoked server. It returns 


either: 


"Yes", requestor number; or"No",0; 


The last invocation "wait"s until something that requires the 


4c 


4d 


4di 
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server’s attention happens. There are two important events that a 
service routine needs to be notified apout. If the last 

capability to a requestor is overwritten so that the requestor 

cannot again be invoked until a new one is created, the "wait" 
returns: 4e 


"Deleted", requestor number, 0; Nil 4el 


The last two parameters, 0 and Nil, are just filler for the 

returned PD and request (see 5c). When a "Wait" returns 

"Deleted", the service routine can recycle any resources being 

used to service tne numpered requestor (e.g. the requestor 

number). 4f 


Tne most important event that causes a "Wait" to return is when 
one of the requestors for tne server is invoked. In this case the 
server returns: 4g 


"invoked", requestor number, PD; request 4gi 


The third parameter, labeled PD, stands for Parameter Descriptor. 

It describes the number of each kind ot parameter passing each 

way during a requestor invocation. Specifically, it consists of 

four numbers: Data bits passed, capabilities passed, data bits 
requested, and capabilities requested. 4h 


The last parameter received, the request capability, is used py 

the serving process to retrieve the passed parameters and to 

return the requested parameters to the requesting process, 
Accordingly, it has the following invocations: ER 


6. Request capability 4ii 
a. "Read parameters"; > {The passed parameters 
D, "Return", {The return parameters}>; 


The "Return" invocation has the additional effect ot restarting 
the requesting process. 4j 


Dne thing that should be noted about the server mechanism is tnat 
invocations on a server’s requestors are queued until the server 
is "wait"ed upon. This is one reason that a request is given a 
separate capability. The serving process can, if it chooses, give 
the request to some other process for servicing, while it goes 
back and waits on its server for more reguests. The corresponding 
situation in the outside bank window analogy would be the case 
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where the teller gives the request to someone else for service SO 
that the teller can return to waiting customers. The request 
capability points pack to the requesting process so that tne 
return can be properiy eftected. 


A sample service, that of the well known semaphore [(8j, is given. 
The semaphore service routine Keeps a table containing the 
semaphore values for each Semaphore that it is servicing, It also 
Keeps a list of queued requests that represent the processes that 
become nung in the semaphore by "F"ing the semaphore wnen it nas 
a value less than or equal to zero. Tne invocations on a 
semapnore are} 


7. Semaphore 
a. WM > : 
Bea ge P 3 


A diagram and flow chart for the semaphore serving process is 
Given in Figures 1. and 2. The fiow charts that are given include 
most of the basic capability invocations, but do not include 
detailed descriptions of table searches. The table structure for 
the semapnore service routine includes entries for each supported 
semaphore. Each entry contains the semaphore value and a link 
into a list of pointers to the requests hung in the semaphore (it 
any). 


The most important feature of the server mechanism is tnat, by 
using it, the functioning of any capability can be emulated. 


This property, similar to the insertion property discussed in 
L9], is the cornerstone of the DCCS. The basic idea of the 
emulation is to have the server "Wait" for requests and pass them 
on to the capability being emulated. Such emulation of a single 
capability is flow charted in Figure 3. The emulation flow 
charted is an overview that doesn’t handle all situations 
correctly. For example, a capability may not return to 
invocations in the same order that they are received. These 
situations also appear in the DCCS, so their handling will be 
discussed there rather than here. Lt is important to note tnat, 
except for delays due to processing and communication, the 
emulation done in the DCCS is exact. 


4k 
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The DCCS Imelementation 5 

The DCCS will initially be described on a network of CCS systems, 
we will assume that there exists a network capability: 5a 
8. Network capability 5al 


a. "Input"; > Host no., message; 
b. "Output", Host NO., message; > ; 


It is assumed that the "Output" invocation returns 
immediately after queueing the message for output and that 
the "Input" invocation waits until a message is available, 


‘For pedagogical purposes, the description of the DCCS will pe 

broken into two parts. First a brief overview of the important 
mechanisms will be given. Tne overview will gloss over some 

important isSues that will be resolved individually in the more 
complete description that follows the overview. 5b 


The intent of the DCCS is to allow capabilities on one host to be 
referenced by processes on other hosts having tne appropriate 
capabilities. to do this, each host keeps a list of capabilities 
that it supports for use by other hosts. Each nost also Stpports 
a server which gives out requestors that are made to appear as it 
they were the corresponding capability supported by the remote 
host. when one of these emulated regquestors is invoked, its 
parameters are passed by the emulating host through the network 
to the supporting host. The supporting host then sees to it that 
the proper capability is invoked and passed the parameters. When 
the invoked capability on the Supporting host returns, the return 
parameters are passed back through the network to the emulating 
host., The emulating host then returns the return parameters to 
the requesting process, DC 


For example, let us take tne "Read" request on a file diagrammed 
in figure 4. when tne emulated file (a requestor) is invoked, the 
emulating process receives "invoke", requestor number, PD; 
reguest, The requestor number that is returned is actually a 
descriptor consisting of two numbers: Host number, capability 
number, These descriptors are called Remote Capability 
Descriptors (RCDs). An RCD identifies a host and a capability in 
the list of capabilities supported by tnat host. After receiving 
a request, the emulating process reads the parameters passed by 
the requesting process and sends them along with the Parameter 
Descriptor to the remote host in an "Invoke" message. 5d 
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When the remote host’ receives this information, it passes the 
parameters to the supported file capability by invoking it and 
specifies the proper return parameters as noted in the Parameter 
Descriptor. when the invoked file returns, the returned data is 
passed back througn the network to the emulating host ina 
"Return" message. The returned data is then returned to tne 
requesting process by performing a "Return" invocation on the 
request capability initially received by the emulating host. When 
the requesting process iS awakened by the return, it will appear 
to it exactly as if a local file had been invoked. 


This works fine when the parameters being passed and returned 
consist simply of intormation, but what happens when there are 
capabilities involved? In this case the routines use the existing 
remote capability access mechanism and pass the appropriate 
descriptors. AS an example, the "Take" invocation on a directory 
is diagrammed in figure 5. The only essential difference is the 
fact that a capability has to be returned., Wnen the capability is 
returned by the invoked directory (or whatever it really is), the 
supporting host allocates a new Slot in its Supported capability 
list for the capability and returns a new descriptor to the 
emulating host. When the emulating host receives the descriptor, 
it creates a new requestor with the returned descriptor as its 
requestor number and returns the requestor to tne invoking 
process. The requestor so returned acts as the capability taken 
from the remotely accessed directory and can be invoked exactly 
as if it were the real capability. 


One important Ching to notice about this mechanism is that 
neitner the emulating host nor the supporting host need have any 
idea what kind of capabilities they are Supporting. The mechanism 
is independent of their type. Also important is the fact that 
neither host need trust the other host with anything more than 
tne capabilities that it has been rigntfuliy oranted, Even the 
DCCS processes themselves need only be trusted with tne network 
capabilities and with the supported capabilities. Finally, note 
that no secret passwords which might be disclosed are needed for 
security. The DCCS directly extends the CCS protection 
mecnanisms. 


A more more complete description of the DCCS will now be given, 
To avoid unnecessary complication, however, several issues such 
as error indications, system restart and recovery, network 
malfunctions, message size limitations, resource problems, etc. 
are not discussed. These issues are not unigue to tne DCCS and 
their solutions are not pertinent here. 


Sf 


5g 


5h 
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As noted earlier, tne complete DCCS must address several issues 
that were glossed over in the initial overview. As these issues 
are discussed, several message types are introduced beyond the 
"Invoke" and "Return" messages discussed in the overview. The 
formats for all the bCCS messages are summarized in figure 6, 


A. 


Timing ~ 


invocations can take a very long time to complete. we saw an 
example in the semaphore capability earlier. An even more 
graphic example mignt be a clock capability that was requested 
to return nothing AFTER 100 years nad passed. Clearly we don’t 
want to nave the emulating process wait until it receives a 
"Return" message from the remote host before servicing more 
invocations, 


Wnat is done in the emulating host is to add the request 
capability to a liist of pending requests after sending the 
"Invoke" message to the supporting host (this is somewhat like 
the semapnore exampie earlier). Tne emulator can then go back 
and wait for more local requests. 


There is a similar problem on the supporting side. we don’t 
want the process waiting on the network Input capability to 
Simply invoke the supported capability and wait for return, 
What it must do is to set up an invocation process to actually 
invoke the supported capability so that pending network input 
can be promptly serviced, The invoking process must then 
return the parameters after it receives them. 


Tnese additional mechanisms add the complication of multiple 
requests active between hosts. These requests are identified 
by a Remote Request Number (RRN). The RRN is an index into the 
list of pending requests. 


Loops ~ 


It nost A passes a capability to host B, and B is requested to 
pass the requestor that is being used to emulate the 
capability pack to host A, shouid B Simply add the requestor 
to its support list and allow A to access it remotely? Jf it 
did, when tne new requestor was invoked on A, the parameters 
would be passed Lob where they would be passed to the 
requestor by the invoking process. Invoking the requestor 
would cause the parameters to be passed back through the 
network to A where the real capability would finally be 
invoked. Then tne return parameters would have to qo throughn 
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the reverse procedure to get pack to A via Ë. This is clearly 
not an optimal mecnanism. 5k14 


„The solution to this problem makes use of the "My requestor?" 


invocation on a server capability described in 5b. When B 

checks a capability that is to be returned to A with tne "My 
requestor?" invocation and tinds that the capability is one of 

its requestors with a requestor number indicating that it is 
supported on A, it can Simply return the requestor number 

(recall that this is really a Remote Capability Descriptor, 

RCD) to A containing the fact that the capability specified is 

one that is local to A ana giving A the index to the 

capability in its supported capability list. 5kż 


Security - 51 


Tne mechanism presented in B. brings up something of a 

security issue. If 6 tries to invoke a capability in A‘s 

Supported list, should A allow B access without question? If 

it did, any host on the network could maliciously invoke any 
capability supported by any other host. To allow access only 

if it nas been granted through the standard invocation 

mechanism, each nost can maintain a bit vector indicating 

which hosts have access to a given capability. It a host does 
receive an invalid request, it is an error condition. 511 


Indirection - Sm 


Tnere is an additional twist on the Loop problem noted in B.a 

This variation comes up when A passes a Capability to B who 

then wants to pass it to C. Here again B may unambiguously 

specify which capability is to be passed by simply sendina tne 
Remote Capability Descriptor (RCD) that it knows it by. The 

RCD indicates that the capability is Supported on A. if C then 
tries to invoke the capability, however, A would probably not 
believe that C snould have access to it. 5m1 


B must tell A, "i, who have access to your i’th capability, 

want to grant it to host CH, To do this, another message type 

is used. The "Give" message Specifies the supported capability 

and the host that it should be given to (refer to figure ô). 

Here again, giving away a capability that you don’t have is an 
error condition. Sm2 


Acknowledgement -= 5n 


There is one last problem with the "Give" message. If B sends 
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the "Give" message to A and then continues to Seng the Remote 
Capability Descriptor (RCD) to C, C may try to use the RCD 

before the "Give" is received by A. For this reason, B must 

wait until A has "ACK"nowledged the "Give" message before 

sending tne RCD to C. This mechanism requires that hosts queue 
un"ACK"nowledged "Give"s, The format for an "ACK" is given in 
figure o. This queueing may be avoiaed for most "Give"S after 

the first for a given RCD, but only at the cost of much 

additional memory and broadcasting "Delete"S (See F. below), 5ni 


F. Deletion zs 50 


lf all the regquestors on A for a given capability supported on 
B are deleted, A may tell B SO that B may: 501 


a. Delete Ars validation bit in the bit vector for the 
specified capability and 


D, If there are no hosts left that require support of the 
given capability, the capability may be deleted from tne 
supported capability list. 

This function reguires a new "Delete" message. 502 


Figure 6 is a summary of the message formats., Figures 7=11 f£low 
chart tne complete DCCS. In the flow charts, abbreviations are 


used to indicate tne directories: 5p 
CSL =- Capability Support List 5p1 
RRL =- Remote Reguest List 5p2 
IPL - Invocation Process List 5p3 


The table manipulation is not given in detail, Three tables are 
needed. The first is associated with the CSL and contains the bit 
vectors indicating access as noted in C., above. The second table 

is associated with the RRL. It contains a host numper for each 

active request. An attempted return on a request by a host other 

than the requested host is an error, The final table is a message 
butter containing the pending "invoke" and "Return" requests. 5q 


In order to avoid hazards in referencing the CSL and its table, a 
semaphore callea the CSLS is used. A message buffer semaphore, 

MBS, iS Similarly used to lock tne message buffer. For tne RRL 

and LPL no locks are needed with the algorithms given. 5r 
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Generalization anda Application 6 


To implement tne DCCS, we assumed a network of CCS systems. The 
specifications of the CCS were, however, very loose. For exampie, 

no mention was made of instruction sets. Any CCS=-like 

implementation could use the mechanisms described herein to snare 
their objects. A process passed to a system with a different 
instruction set, for example, could be used as an efficient 

emulator. e ba 


The most important generalization of the DCCS is to note that a 

given implementation nas no idea what kind of host it is talking 

to over the network. Any sort of host could implement a protocol 
using the messages given. For example, a Single user system might 
allow its user to perform arbitrary invocations on remote 
capabilities and keep a table of returned capabilities. Such a 

system might also support some Kind of Standard terminal 

capability that could be given to remote processes. Ona 

multi-user system, similar functions could be performed for each 
user. ob 


in some sense, any system implementing the DCCS protocol becomes 

a Cerlist system. The single user system could, for example, set 

up remote processes servicing remote server capabilities giving 

out reguestors to the single user system or any other systems, 
Returns from invocations could appear on the Single user's 

terminal by remote invocation of the terminal capability, etc.. GC 


Implementing the DCCS on noneCwlist systems is similar in some 
respects to what happened with some host to host protocol 
implementations on the Department Of DCefense’s ARPA network [10]. 

The ARPA network host to host protocol allows a process on one 

system to communicate with a process on another. Many of the ARPA 

net protocol implementations had the effect of introducing local 
process to process communication in hosts tnat formerly nad none. 6d 


Applications oe 
I. Single copy Gel 


Tne first application is a solution to what I have dubbed 
the single copy problem for information resources. Whenever 
a process receives information from an information 
resource, it can only receive a local copy of the 
information. This fact is apparent when the information 
comes from a distributed data base, but is also true in 
tightly coupled virtual memory situations where information 
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from shared memory must be copied into local registers tor 
processing. Gnce a process bas a local copy of some 
information, it might like to try to insure that the 
information remains current, i.e. that it is the single 
copy. 


The traditional solution to this problem is to lock tne 
information resource with a semaphore before making a local 
copy and then invalidate the local copy before unlocking 
the resource. This solution suffers from the fact that, 
even though other processes may not be requesting the 
copied data, the data must be unlocked quickly just in 
case, This can result in many needless copies being made, 


wnat is needed is a mechanism for invalidating local copies 
exactly when requests by other processes would force 
invalidation. to offer such a mechanism, an information 
resource can have, in addition to the usual reading and 
Writing invocations, the following: 


"Write lock", portion; > ; write notify 
"RW lock", portion; > ; RW notify 

The important invocation on the notify capabilities is: 
"walt for notification"; > Treason; 


The basic idea is to allow a process to request that it be 
notified if an attempt is being made to invalidate its 
copy. If the copy is used for reading only, the process 
need only request notification of attempted modifications 
of the data ("Write lock"). When a process is so notified, 
it is expected to invalidate its copy and delete its write 
notify capability to inform the information resource server 
that the pending write access may proceed, 


in the read write lock case, the Rw notify capability may 
also oe used for reading and writing the portion. Any other 
access to tne portion will cause notitication. When 
notified, the process with tne Rw notify capability is 
expected to write back the latest copy of the information 
before deleting its RW notify capability. 


Space does not permit presenting more details for this 


mechanism. The important fact to notice is that it permits 
an information resource to be shared in such a way that, 
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though the information may be widely distributed, it is 
made to appear as a single copy. This mechanism nas 
important applications to distributed data bases, 


Ii. Network resource optimization be? 


The application that probably best demonstrates the 
usefulness of the DCCS is the sort of network optimization 
that it facilitates. To illustrate, let’s first introduce a 
capability that can be used to create at least the 
primitive capabilities introduced earlier: 


9. Account capability 
a. "Create", type; > } Capability 


Tne passed type parameter could at least be any of: 
"File", "Directory", "Process", or "Server". The 
appropriate type of capability would be returned. The 
resources used for the capability are charged to the 
particular account. 


Now suppose that a user on one CCS system within a DCCS 
network has remote access to account capabilities on 
several other CCS systems. This user could create what 
Mignt pe calied a Super account capability to optimize use 
of his network resources. The super account capability 
Would actually be a requestor serviced by a process with 
the user’s real account capabilities, Tne kind of 
optimization desired would be completely under user 
control, but some of the more obvious examples are 
presented: 


1. Static object creation optimization 
a. When a new file is requested, create it on the 
system with the fastest access or the least cost per 
bit. 
De When a process is requested, create it on the 
system with the fastest current response or with the 
least cost per instruction. 

2. Dynamic optimization. 


To do dynamic optimization, the super account would 
not give the requesting process the capability tnat 
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it received from the remote account after its static 
optimization, but would give out a requestor that it 
would make function like the actual capability except 
optimized. 


a. When network conditions or user needs change, 
files can be moved to more effective systems. 
Changes in cost conditions might resuit in file 
movement. Changes in reliability conditions mignt 
result in movement of files and/or in addition or 
deletion of multiple copies, 


be If system load conditions or CPU charges 
change, it might be effective to relocate a 
process. The super account service process could? 
create o new process on a more effective system, 
stop the old process, move the old Celtist and 
memory to the new process and start the new 
process up. The emulated process given to the user 
would never appear to change. 


Ce Similar optimizations can be done on any other 
capabilities. 


Such a super account can automatically optimize a 

user’s network resources to suit the user's needs 

without changing the functional characteristics of 
the objects being optimized. 


Final Note 7 


The DCCS mechanisms defined in this paper are currently being 
implemented on a Digital Equipment Corporation PdDP=-11/45 computer 

for use as an experimental protocol on the ARPA computer network 
[10]. fne DCCS protocol will also form the basis for a gateway 
between the ARPA network and Energy Research and Development 

Agency’s CTR network [11]. it is the authors hope tnat the DCCS 
mechanism will hasten the approach of the Kind of networks that 

are needea to create a truly free market in computational 

resources, Ja 


16 


NWG/RFC# 712 JED 27-FEB-76 18:25 34586 
-A Distriouted Capability Computing System (DCCS) 


Acknowledgements 8 


Tne author would like to thank the administrators and Statt of 

the Computer Research Froject at the Lawrence Livermore 

Laboratory for creating the kind of environment conducive to the 
ideas presented in this paper. Special thanks are due to Charles 
Landau tor many of tne Cellist ideas as implementeda in the current 
RATS system. 8a 


17 


NWG/RFCaA 7i2 JED 27-FEB-76 18:25 345966 
-A Distributed Capability Computing System (DCCS) 


References 9 


L.C, R, Landau, The RATS Operating System, Lawrence Livermore 
Laboratory, Report UCRL=-77378 (1975) 9a 


Ze. C. Ra Landau, An Introduction to RAIS (RISOS/ARPA Terminal 
System): An Operating System for the DEC PDP=11/45, Lawrence 
Livermore Laboratory, Report UCRL=51582 (1974) 9b 


3. J. E. Donnelley, Notes on RATS and Capability List Operating 
Systems, Lawrence Livermore Laboratory, Report JUCiD=-i6902 (1975) 9c 


4. B. We Lampson, "On Reliable and Extendable Operating Systems”, 
Techniques in Software Engineering, NATO Sci Comm. Workshop 
Material, Vol. Ii (1969) 9d 


D, We. Wulf, et. ale, “HYDRA: The Kernel of a Multiprocessor 
Operating System", Communications of the ACM 17 6 (1974) 9e 


D, P. Neumann et. al., "On the Design of a Provably Secure 
Uperating System", international Workshop on Protection in 
Operating Systems, IRIA (1974) 9f 


7. Re S. Fabry, "Capability-Based Addressing", CACM 17 7 (1974) 9g 


8. E. we. Dijkstra, "Cooperating Sequential Processes," publisned 
in Programming Languages, E, Genuys, editor, Academic Press, pp. 
43-112 (1968) 9h 


9. F. A, Akkoyunlu, et. al., "Some Constraints and Tradeot£s in 
the Design of Network Communications", Proceedings of the Fifth 
Symposium on Operating System Principles, Vol. 9 No. 5 pp. 67-74 
(1975) ER 


10. L. G., Roberts and B., D, Wessler, "Computer Network 
Development to Achieve Resource Sharing," AFIPS Conference 
Proceedings 36, pp. 543-549 (1970) 9j 


11. "National CTR Computer Center", Lawrence Livermore Laboratory 


Energy and Technology Review, Lawrence Livermore Laboratory 
UCRL©52000"-75"12, December (1975) 9k 


18 


NWG/RFCH 712 JED 27-FEB-76 18:25 34586 
-A DpiStributed Capability Computing System (DCCS) 


10 
Tne figures are not included in the online version. interested 
readers Can obtain a hardcopy version of the document including 
the figures by requesting a copy of UCRL-77800 from: 10a 
Technical Ilntormation Department 
Lawrence Livermore Laboratory 
University of Calitornia Livermore, Calitornia 94550 106 
Questions or comments would be appreciated anc should be directed 
to the author; toc 
Through tne U. S, mail: 10c1 
James E. Donnelley 
Lawrence Livermore Laboratory L=307 
D, O. Box 808 
Livermore, Californie 94550 
By telephone: l 10c2 
(415)447=1100 ext. 3406 
Via ARPA net mail: 10c3 
JED@BBN 
"This report was prepared as an account of work sponsored by the 
United States Government. Neither the United States nor the 
United States Energy Research & Development Administration, nor 
any of their employees, nor any of their contractors, 
subcontractors or their employees, makes any Warranty, express or 
implied, or assumes any legal liability or responsibility for tne 
accuracy, completeness or usefulness of any information, 
apparatus, product or process disclosed, or represents that its 
use would not infringe privately-owned rights." 10d 


19 


< GUGURNAL, 34586.NLS371, >, 27-FEB=-76 21:34 XXX 3733 Titles 

Author(s): James E, (JED) Donnelley/JED; Distribution: /JBP( (¢ INFO-ONLY 
] ) JAKEC [ 1INFŪ-ONLY J ) | Sub-Collections: NWG NIC; REC# 712; Clerk: 
JAKE; Origin: < NELiNFO, RFC7T12.NLS;Z, >, 27-FEB=76 15:22 JAKE 
tree DEER 


